A long time ago, in FFF-191 I wrote about improving the GUI. Well, things are finally starting to move, so this week I'll bring you an update on that. We even have a GUI team: Twinsen(me): UX and programming Albert: UI, graphical design, layouts, mockups, UX Rseding91: main programming and GUI internals The plan is to go through the entire game's GUI (including main menu, all entity GUIs and all game windows) and improve it both visually and interaction wise. This is quite a huge undertaking because: Factorio's interactions are quite complex If you count all the entity windows and panels, we have about 120 windows to go through in the game. Mods can change many aspects of the game so we have to account for that to make sure windows still look good and are still easy to use: e.g. having 15+ recipe categories, having assembling machines with 20+ module slots, having recipes with 20+ ingredients, having players with 200+ inventory slots, etc. Many players are already used to interacting with the game in a specific way, so any major changes are hard to make. Our GUI back-end (heavily modified AGUI) is not exactly well written, programmer-friendly, or feature-rich. Many of the features and polishing we want to add were not done previously due to their programming complexity. At the moment we are still early in the project, just defining the style and the concepts. During the next months, I'll try to make a series of FFF talking about the improvements we are making (starting with this one) so you can see how the project progresses, and offer feedback along the way. Everything I mentioned in FFF-191 will be there, but we have even more cool improvements coming to the toolbar that we are working on, so today I'll talk about something else: the new train/locomotive GUI. Disclaimers: Everything you see are mockups made by Albert and are not from the game, but we will try to make it look almost identical in game. The style (colors and look) is not final. This is the 3rd iteration and Albert is still experimenting with making everything look nice. The purpose of these mockups are mostly to define the layout and interaction. This is how the new Locomotive GUI will look. As you notice, apart from the style changes, they way the stations and conditions are shown is very different, but I'd say much more intuitive, informative, and easy to use. Let's go through a short use case. You click add station and the list of stations appears. You can add a station by clicking on the station in the list or by clicking it in the small map. The map can be zoomed and moved around so you can easily find your station. Also, as you hover over stations in the list, the map will show their location. The stations marked differently are unreachable from the train's current position. This way you can more easily recognize and possibly ignore stations outside of the current network. Once you click a station, it is added to the schedule, along with a default condition. You can continue adding more stations, or add/edit the conditions for the new station. Finally a schedule can look something like this. The path of the train will be shown. We will try to paint the path the train is taking at the moment, it will change as the train takes different paths. The fuel can be accessed from the separate tab and the color of the locomotive can be changed using the color picker. The buttons in top of the map, from left to right are as follows: Turn station names on or off. Change the angle of the station names. Switch to map view. Switch to camera view. Center view on the train. The small 'info' button you see on the right side will be a help button we will use throughout the game to help explain how different GUI work and when their elements mean. We will write more about this in some of the next parts of the FFF GUI update series. We also want to add a neat tool for advanced players. Control-clicking on any point on the locomotive's map (or any station) will add a 'Temporary stop' to it's schedule. The train will try to go as close as it can to that point, wait a few seconds and finally automatically remove the 'Temporary stop' from it's schedule. This is very useful for quick transportation. It also allows you to quickly 'hijack' an existing train and use it to get somewhere, since the 'Temporary stop' will be deleted and the train's normal schedule will be resumed. Another quality of life improvement will be a game option to automatically add some fuel from the player inventory when building vehicles (car, tank or locomotive), making rail transportation as simple as placing a locomotive on a rail, entering it and control-clicking where you want to go. We hope you like the proposed changes. No doubt things will change as we implement and playtest these changes, but we thought it would be interesting to show you an early preview. Finally the million dollar question is when will this be in game? Because it's quite a bit of work we already pushed the GUI update to 0.17. On the bright side, this mean 0.16 will come a bit sooner. Let us know what you think by commenting in our usual topic at the forums.

Hello, after a lot of planning and preparation, the party on Saturday went very well. We really enjoyed spending time with some of our fans, and it has definitely sharpened our motivation to do right by our community and make the game as great as possible. With this festivity behind us, we started this week with some renewed focus.

Since all of us are fixing bugs, there is not much to report. So I will take this opportunity to rant about game design, gameplay design and UI. Please note that these are my (Twinsen) personal opinions and do not necessarily reflect Factorio's direction. Nonetheless it should make for an interesting Friday Facts.

0.15 release I would be surprised if you are reading this blog and didn't know that we released the 0.15 experimental this Monday. After more than 6 months of work and effort put in, we are really happy to finally see everyone playing and enjoying it so much. We'd like to thank you all for the feedback and suggestions we've received, and for being patient with us when we couldn't keep to our plans. The whole team here is committed first and foremost to making as great a game as possible. While the delays were not insignificant, we really hope we have met your expectations and delivered on what we have promised. Initially we had a small issue with our new config system and a script we use for Steam cloud syncing, leading to the game looking for a value which was no longer there. Thankfully HanziQ solved the problem in short time, and we released 0.15.1 just 3 hours later. The rest of the week ran pretty smoothly with the typical bugfixing, while the majority of the GFX department takes a well deserved break. If you are interested in seeing an overview of all the new features, you have a choice of British or American flavour, provided by MangledPork and Xterminator respectively:

The programmable speaker There has always been some talk around the office about a music box that can be used to make simple sounds, you could even connect it to the circuit network and make simple songs. I put it on my long list of circuit network ideas, and in the past few week it has been coming to life. So today I'll be talking about an exciting new entity coming in 0.15: the Programmable Speaker. It was designed to do two main things: Show configurable GUI alerts and play audio alerts based on circuit conditions. Play audio samples as controlled by the circuit network in a way that simple songs can be created. The entity graphics are placeholder programmer graphics. Let's start with the useful part, it's pretty straightforward. You set your circuit condition, set the sound you want it to make, set whether the sound should be heard in that part of the factory or across the entire map and add an optional GUI alert message. When the circuit condition is true, the speaker will play the selected sound and show the optional GUI alert. You can let the sound play continuously or use simple combinator logic to make the sound at custom intervals. And now that fun part. We knew we wanted the Programmable Speaker to be able to make simple songs. Crazy ideas started to pour in, and it was quickly becoming a full-blown music production DAW with custom synthesizers and control over everything. But this has to be easily controlled by the circuit network without having to build real-time computers with combinators. So in the end I made the Programmable Speaker work as a step sequencer. If you send a circuit network signal pulse, an audio sample will start playing, otherwise nothing will happen. There is no control over the sample length or any special effects, but this means it is quite easy to control it using the circuit network. Enough talk. Here is a demo of a song made using the samples already included. Everything you hear is created inside Factorio. I will leave it to you to analyze the video and figure out how the song is generated. Modders can easily add more audio samples to the entity, including custom alerts. I imagine there will be a voice pack mod that could be programmed using combinators to speak things like "Crude oil is low". I'm sure the Programmable Speaker will be part of some very interesting posts on the Factorio Reddit. There are some other circuit network improvements coming to 0.15, but I will talk more about them in some other FFF. The map download struggle (Technical) For as long as I can remember, our multiplayer map downloader had (among other problems) the problem that it would get stuck at 100%. It was an extremely rare problem some random person would report. We would keep ignoring the bug throwing it in "Pending" or "Duplicates" or "1/0 Magic", but after a few months some other person would report it again. I seem to have a habit of obsessing over these rare "unfixable" bugs (audio mixer crashing, vsync performance issues, non-pixel-perfect sprite drawing), so I started looking into this map downloader issue. First I was looking at the map downloader code itself, thinking surely there is something wrong there. This was a long process because I had no way of reproducing the issue, so it usually involved going back and forth with a person who was experiencing the issue. I would create an executable that would create detailed logs, that person would run the game using that, I would investigate the logs and see that our map downloader works correctly. The I would add more logging and so on. By the time I would reach some kind of conclusion that person would stop answering and probably stop playing Factorio. But near the end thanks to some helpful players, I was able to see what was happening. Looking at the wireshark capture for both the client and the server, it seems that a packet with a specific content or a specific checksum always gets filtered. Some cheeky firewall from the computer, router or ISP is looking inside the packet data and blocking the packets it does not like. No matter how many times I resend that packet, it never gets through, while all the other hundreds of thousands of game and map packets have no problem getting through. Correct me if I'm wrong, but something like this should not be happening. You can read all the details and see the packet data last posts of the forum topic. The issue seems to be resolved if I add one byte of random data to the packet, but I would like to know why is this happening in the first place. If you know what is happening or you know someone that might, please don't hesitate to enlighten us :) This shows how hard it is to make software that "just works" for everyone. There will always be that 0.1% of people who end up having problems that no one could have ever foreseen. Big thanks to admalledd, dadymax, Rippie and the other forum members who helped or are still helping me investigate this odd issue. In other good news, while Rseding91 was also looking at the map download code trying to investigate this problem, he found we had some slow code doing hard drive seeking, slowing down map uploads. He improved it and you should see better map transfer speeds on LAN and high speed connections. As usual, let us know what you think at the forums.

Combat Balance Twinsen here. As you might have read in Friday Facts #166, we wanted to do some combat balancing. First, to not bring the hopes of everyone up too much, this did not mean a combat overhaul. It means mostly tweaking numbers to make the game more fun and make some of the the weapons more viable. No new entities or new mechanics. As I was doing the combat balance, it was clear the everyone has their own different opinion of how combat is, how it should be and how to make it "better". It's hard to please everyone, especially when you are just tweaking numbers. To try to objectively evaluate combat I used the following methodology. As the game progresses, the player's power increases through research, but so do the biters(mainly due to evolution factor). So I split the game in 7 sections based on research progress. Each section also has the evolution factor I tested biters will approximately have in an average game. Initial - 0 evolution Red - 0.1 evolution Red+Green - 0.3 evolution Red+Green+Military - 0.4 evolution Red+Green+Blue+Military - 0.7 evolution Red+Green+Blue+Military+High Tech - 0.9 evolution Red+Green+Blue+Military+High Tech+Production - 0.99 evolution Then for each section I tested both offensive combat and defensive combat using the available guns and turrets and tweaked the numbers accordingly. While tweaking the numbers, I keep this in mind (this is not a complete list): Fun always wins: I prefer changes that are more fun and less annoying even if it means it could be slightly unbalanced. New weapons should be slightly more powerful than old weapons, to incentivize you to experiment. So near the end game, a rocket launcher will be better than the machine gun. Destroying biter bases is hard in the beginning and significantly easier toward the end game, to give the sense of combat power progression. Defending is not too hard in the beginning. I try not to put a new player in the situation of "you didn't prepare properly, you have to start a new game, because no matter what you do you will get killed". Then throughout the game you have to upgrade your defenses as the biters evolve. So far, the changelog looks like this. There are many numbers that were tweaked and are not included in this list. Player regains health at a much higher rate, but only after being out of combat for 10 seconds. Discharge defense equipment pushes back, stuns and damages nearby enemies when activated by the remote. Decreased the size of Discharge defense equipment from 3x3 to 2x2. Greatly increased the damage of Personal Laser Defense Equipment. Flamthrower gun has a minimum range of 3. The flames created on ground from the flamethrower significantly increase in duration and damage when more fuel is added to them by firing at the same spot. Increased fire resistance of biter bases. Increased the health of player non-combat buildings. Increased player health from 100 to 250. Increased collected amount and effectiveness of Raw Fish. Increased the damage, range and health of biters worms. Decreased health and resistance of Behemoth biters. Doubled the stack size of all ammos. Tweaked the cost and crafting time of some ammos. Increased the damage of most player ammos. Greatly increased the damage and fire rate of Rockets and Cannon Shells. Increased the collision box of Cannon Shells. Increased Tank health and resistances. Added research for Tank Cannon Shells damage and shooting speed. Tweaked research bonuses and added more end-game research for military upgrades. Greatly increased the damage of Mines. They also stun nearby enemies when they explode. Biters stop following player after 10 sec of not giving or receiving damage if the player is more than 50 tiles away. Other minor changes. As usual, these changes are not final and will probably change to some degree as we playtest more. There are still many things to be done. We are always talking about more end-game weapons, so don't worry, the combat in the late-game will be even more worry-free. There is also one thing that we always talked about trying to remove: turret-creep (destroying biters base building turrets closer and closer). This method is very powerful and usually doesn't cost anything. So far I believe that we did not find a simple, fun and fair solution. Ideas include: large power-up times(annoying and also weakens base defense); simply not allowing turrets to be build near biter bases (makes the player feel cheated); underground anti-turret worms (sugar-coated version of the previous idea). With the combat changes that were done I believe there is almost always an option to destroy bases without being forced to use turret-creep.In the end maybe your ingenuity and effort of building all those electric poles should be rewarded; If the player wants to do it that way, why not let him? Let us know what you think.